The inclusion of embedded processors in programmable-logic devices has enabled system-on-chip developers to benefit from the traditional time-to-market advantages of programmable logic. By following the tips and procedures outlined in this article, floor planning can be a valuable resource in planning, designing and implementing an embedded system within an FPGA.
Floor planning allows designers to control placement and grouping of the embedded processor, the associated intellectual property and their custom logic, thereby simplifying the process of complex system-on-chip development and increasing design performance.
The use of a floor planner in the development of an embedded system can be demonstrated by an example system that integrates a PowerPC core with a DDR memory controller and an LCD controller. The PowerPC 405-based embedded system connects the DDR memory controller to the PowerPC via a high-speed processor local bus (PLB), enabling high-speed memory access for instruction and data transactions (Fig. 1).
The lower-bandwidth requirements of the LCD controller enable it to be connected to the PowerPC via the slower on-chip peripheral bus (OPB), which links slower peripheral cores to the PLB via a PLB-to-OPB bridge. The example also illustrates the use of two on-chip memory controllers and the block RAM in the FPGA. This embedded-system design could easily support the addition of other bus controllers.
The design and creation of an embedded system is simplified by using a system generator to define the parameters of the desired processor (and associated controllers) and generate the source design of the embedded system-generally including a processor core, bus structures, as well as existing IP. The system generator will also produce the software header files.
These tools allow hardware and software designers to begin developing the embedded system in parallel. For hardware designers, the system generator creates all the files necessary to assemble all the key components of the system and automate tasks such as peripheral definition, peripheral creation and the connection of hundreds of pins on the processor, peripherals and system buses. If a system generator is not available, the system generation must be done manually, increasing hardware design time and complexity.
The floor planner tool then allows the hardware designer to control the placement of the logic related to any functions that are of interest, and to view the layout once it's been implemented within the device. In the embedded-system example, the floor planner can be beneficial in helping the designer view and control the placement of the processor and the associated peripherals. In some instances, the placement of these peripherals may play a critical role in meeting the design performance requirements.
The PowerPC 405 core's OCM controller provides an interface to both the 64-bit instruction-side block RAM (ISBRAM) and the 32-bit data-side block RAM (DSBRAM). The OCM controller is capable of addressing up to 16 Mbytes of DSBRAM and 16 Mbytes of ISBRAM. One of the primary advantages of the OCM is that it guarantees a fixed latency of execution. To meet this timing requirement in an FPGA, the hardware designer must control the placement of the OCM block RAM (BRAM) with respect to the OCM controller interfaces. The DSBRAM must be placed above the PowerPC 405 core, while the ISBRAM must be placed below. The floor planner is one way-perhaps the easiest-to control this relative layout.
While a floor planner makes it possible to view and place logic, there are several tips a user should follow for successful floor planning.
Tip 1. Before a hardware designer begins to lay out the floor plan of your design, make sure he or she has detailed knowledge of the design and the target architecture. This knowledge is critical when determining correct design placement and hardware utilization.
Tip 2. The physical layout of an FPGA yields itself to an optimal I/O layout. I/O for control signals should be placed on the top or bottom of the FPGA, and I/O for the data buses should be placed on the left or right. This ensures the most effective use of the FPGA routing resources and, as such, optimal performance.
Tip 3. Arithmetic functions generally utilize dedicated carry-chains. Carry-chains run in a specific vertical orientation. For example, a 10-bit counter will have a carry-chain that runs vertically from the bottom to the top of the device. By placing the least significant bit of your bus at the bottom and the MSB at the top, the design takes advantage of this orientation.
Tip 4. A floor planner will display the logic by hierarchy, making it easy to organize the logic into a common group or area. Grouping by hierarchy takes advantage of the local routing resources, thereby decreasing the routing delay and increasing circuit performance.
Tip 5. By interleaving related I/O buses, the hardware engineer can reduce routing delays. This technique is valuable as long as the buses do not feed additional logic. Remember to look at the design as a whole when making layout decisions.
To begin floor planning an embedded system, the designer must first assign the logic to different groups. A typical group is based upon the design hierarchy, which provides a natural boundary in an embedded system and can easily be used by a floor planner for group creation. Floor planners usually provide three methods for constraining individual logic blocks or groups to physical locations.
Logic constraints
The first method involves placing the logic component in a specific physical location or component. For example, a designer can assign bit 10, an output of a data bus, to pin 37 on the device. This type of assignment does not allow for any flexibility: The place and route tools must place the output driver for bit 10 in pin 37.
The second method involves assigning the logic, or a group of logic, to a physical area. This method is commonly used because it allows the place and route tools to move the logic inside the area group to obtain an optimal placement and routing. This method will be demonstrated below.
The third method involves the creation of relationally placed macros (RPMs). An RPM defines the layout of the logic elements relative to one another. However, for optimum design, the place and route tools determine the exact placement of that logic.
A simpler example-an embedded design consisting of just the PowerPC 405, several UARTs and a BRAM controller-will illustrate some of the tips and methods discussed (Fig. 2). For this design, groups are created on the hierarchical boundaries, which are created in their turn by the system generator. An area group can consist of the PLB arbiter, UARTs and block RAM memory controller. To maximize design performance, the BRAM and PowerPC 405 are constrained to specific locations.
An example of a floor plan for this design is shown in Fig. 3. It should be noted that an area group assignment must allow sufficient resources for the logic confined to that area. More powerful floor planners can provide the user with the number of resources required for each area group. The area groups in this example contain twice the resources required for the implementation. This allows for further optimization of the design by allowing additional logic (not included within the group) to be placed within the floor-planned area.
The BRAM memory controller was assigned to the center of the die, allowing for equal access to all the BRAM components and the PowerPC 405 core. The block RAM in this design contains the data and instructions for the PowerPC 405. UART1 and UART2 are located close to the I/O, which allows for minimal input-to-clock and clock-to-output times. There are two PLB masters, the CPU instruction-side PLB interface and the CPU data-side PLB interface. Because of this, the PLB arbiter is placed close to the PowerPC 405 core. The resulting implementation is shown in Fig. 4.
As one can see, the logic assigned to each area group has been placed according to the area constraint. Also, additional logic has been intermixed, to increase the design performance.
---
Paul Glover, product applications engineer, joined Xilinx as a customer applications engineer in 1997. His responsibilities span product definition to customer support and education. Glover holds a BSEE degree from the University of Utah.
http://www.isdmag.com
Copyright © 2002 CMP Media LLC
3/1/02, Issue # 14153, page 20.
